John Daane
Altering Altera's Course

A large company doesn’t handle like a sports car. You don’t streak down the speedway of success sensing the track through tightly linked steering and suspension components with refined controls ready to respond instantly to your slightest subtle input. It’s more like sailing a large racing yacht into the wind. Every maneuver needs to be planned in advance with the crew carefully choreographed. Together, you work against the competition and the elements, trying to reach the next mark first without anyone being knocked overboard by the boom. You reach your destination obliquely through a series of angled maneuvers, never traveling in a straight line. When a competitor gets ahead and steals your wind, you need to turn and tack away, setting a new course, looking for your own clear air where you can fill your sails again, accelerate back up to speed, and position yourself to recapture the lead.

In November 2000, when John Daane took the helm at Altera, it was time to tack. The company had become complacent with their lead in CPLDs, and as the market winds shifted and boom turned to bust, Xilinx took a commanding lead in the new FPGA-centric programmable logic market. Daane immediately took action, bringing Altera’s efforts into focus on a small number of high-value projects. “Altera has excellent people,” says John. “I saw a huge number of projects underway and not enough energy on the key efforts that would make us successful. We cancelled a lot of programs and put our energy behind the few that were critical.”

Those critical projects included correcting the problems with Altera’s struggling design tool suite and subsequently readying the then-new Stratix family for launch. A much-improved version of Altera’s Quartus design tools was needed to make customers successful with any new future architecture. While the original Quartus suite had been ambitious, it was feature-heavy and performance-light and had been suffering from a lack of maturity since its launch. A new and improved version--Quartus II--made a huge leap forward in performance, reliability, and robustness and, from a design tool perspective, put the company back on its feet again.

Stratix was a new, vastly improved architecture that would be the basis for a number of future product lines. Outsiders gave the project little hope of shipping on time, but Daane knew better. “First, we had complete confidence in TSMC-- our partnership with them was so strong that we were part of their de-bug process. Second, and most importantly, is that there is a lot of talent at this company, and people are willing to work hard to get things done. There was still a fierce competitiveness in the staff despite the hard times they’d been through.” The company executed well and launched the product on schedule. [more]

Debugging Processor-based FPGA Designs
by Rick Leatherman, President & CEO, First Silicon Solutions (FS2)

Highly integrated FPGA designs built around RISC cores require new debug methods

FPGA companies seem to be announcing higher density devices on a quarterly basis. Multi-million-gate devices that seemed unimaginable just a year ago are shipping in volume today. Rushing to fill the millions of available gates is a myriad of synthesizable IP including sophisticated RISC and DSP cores and countless peripheral devices. As a result, FPGA devices are getting a serious look by design engineers contemplating either a small to medium size ASIC or ASIC designs where the run-rate of the final product is of questionable size. An easy migration path to structured ASIC-like devices makes the FPGA choice even more attractive.

Embedding RISC and DSP cores, busses, and peripheral devices presents a new challenge to the tried and true methods of FPGA debug. These devices are now falling into the lap of software engineers for whom issues like gate delays and timing closure are new and foreign concepts. While the configurable on-chip logic analyzers provided by the major FPGA vendors are indispensable for debugging the FPGA fabric, they are of little help in dealing with uninitialized variables, failing device drivers and software performance issues. Fortunately FPGA vendors have partnered with 3rd party tool providers to address the debug issues faced by the software engineer.

Enter On-Chip Instrumentation (OCI™)

Processors and DSP have benefited from a host of tools over the years like In-Circuit Emulators (ICE) logic analyzers with disassembler probes, Background Debug Mode (BDM) and the like. The latest generation of programmable logic offers all of this and more in integrated environments that let you methodically build an FPGA-based SOC or SOPC and at the same time construct the debug tools for development and software debug.

Debug features require gates, and while most FPGA designs have plenty of extra gates to allocate to debug, there can be exceptions. Cost sensitive applications are one of those cases where gate utilization is paramount. Typically the FPGA embedded debug tools are completely scalable, giving the engineer a broad range of feature options versus required gates. In this scenario a design team will typically prototype in a larger device giving them access to all of the debug tools. When it comes time to retarget the design to a smaller device, the debug capability can easily be scaled back to live within the available gates. [more]